fix(engine): Prefer js_error! over JsError::from_opaque#5116
Merged
jedel1043 merged 1 commit intoboa-dev:mainfrom Mar 28, 2026
Merged
fix(engine): Prefer js_error! over JsError::from_opaque#5116jedel1043 merged 1 commit intoboa-dev:mainfrom
js_error! over JsError::from_opaque#5116jedel1043 merged 1 commit intoboa-dev:mainfrom
Conversation
github-actions
Bot
added
the
Waiting On Review
github-actions
Bot
added
the
C-Builtins
Test262 conformance changes
Tested main commit: |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5116 +/- ##
===========================================
+ Coverage 47.24% 59.72% +12.48%
===========================================
Files 476 589 +113
Lines 46892 63471 +16579
===========================================
+ Hits 22154 37909 +15755
- Misses 24738 25562 +824 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jedel1043
requested changes
Mar 19, 2026
Member
jedel1043
left a comment
jedel1043
left a comment
There was a problem hiding this comment.
Looks good, just a couple of nits
Comment on lines
+62
to
+88
| @@ -85,7 +85,7 @@ macro_rules! impl_into_js_function { | |||
| match s.try_borrow_mut() { | |||
| Ok(mut r) => r( $($id,)* rest.into() ).try_into_js_result(ctx), | |||
| Err(_) => { | |||
| Err(JsError::from_opaque(js_string!("recursive calls to this function not supported").into())) | |||
| Err($crate::js_error!(ReferenceError: "recursive calls to this function not supported")) | |||
Member
There was a problem hiding this comment.
These should also be plain Errors, right?
In a few places, native code was throwing
`JsError::from_opaque(js_string!("some literal"))`. This is allowed, but
it is not exactly standard: most users will expect thrown values to be
of type `Error`.
So, where possible, let's convert code using that to instead use the
provided `js_error!` macro, which does generate proper `Error` objects.
This doesn't touch `AbortError`, because (1) that's a larger code
change, and (2) it might actually be relied on as a sentinel value.
p0lyw0lf
force-pushed
the
js_error-instead-of-from_opaque
branch
from
e5bd33f to
494a286
Compare
Contributor
Author
|
Hi, sorry for the delay on this! I've addressed the nit & rebased past the merge conflict. |
Test262 conformance changes
Tested main commit: |
github-actions
Bot
removed
the
Waiting On Review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In a few places, native code was throwing
JsError::from_opaque(js_string!("some literal")). This is allowed, but it is not exactly standard: most users will expect thrown values to be of typeError.So, where possible, let's convert code using that to instead use the provided
js_error!macro, which does generate properErrorobjects.This doesn't touch
AbortError, because (1) that's a larger code change, and (2) it might actually be relied on as a sentinel value.